home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000069_gadia@cs.iastate.edu _Mon Apr 5 16:00:01 1993.msg < prev    next >
Text File  |  1996-01-31  |  5KB  |  141 lines
  1. Message-Id: <199304052100.AA20412@optima.cs.arizona.edu>
  2. Received: from ren.cs.iastate.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA20412; Mon, 5 Apr 1993 14:00:07 MST
  4. Received: by ren.cs.iastate.edu
  5.     (16.8/16.2) id AA11832; Mon, 5 Apr 93 16:00:03 -0500
  6. From: Shashi K. Gadia <gadia@cs.iastate.edu>
  7. Subject: Valid/Transaction times orthogonality
  8. To: tsql@cs.arizona.edu
  9. Date: Mon, 5 Apr 93 16:00:01 CDT
  10. Cc: gadia@cs.iastate.edu
  11. Mailer: Elm [revision: 70.30]
  12.  
  13. The following discussion is about  
  14. why the valid and transaction times 
  15. are orthogonal.  It arose in correspondence 
  16. from Fabio Grandi.  I though it may be 
  17. of general interest, so I wrote it in 
  18. a more context free style.  You may read it 
  19. if you are interested. 
  20.  
  21. =================================================
  22.  
  23.  
  24.  
  25. Pure valid time v/s pure transaction time.  
  26. ------------------------------------------
  27. The obstacle in our appreciation of the 
  28. orthogonality between the valid and transaction 
  29. times is that we typically tend to think of 
  30. valid time in isolation, but we do not think of 
  31. transaction time in isolation.  So let us try 
  32. to think of the two times in isolation.  
  33.  
  34. Valid time database.
  35. --------------------
  36. For valid time, let us suppose there is a 
  37. wizzard with E.S.P. The wizzard has the 
  38. following capabilities:
  39. A. The wizzard knows what is changing in the 
  40.    real world, as and when it changes.
  41. B. The wizzard can remember all the past 
  42.    changes.  
  43. C. The wizzard can assemble all his 
  44.    knowledge in a coherent form which is 
  45.    what we call a valid time database. 
  46.  
  47. The problem is that a wizzard as postulated 
  48. above does is not feasible in practice.  So 
  49. in valid time databases, what we do is 
  50. that we first assemble a version of histroy.  
  51. Then we allow portions of histories to be 
  52. updated through update operations.  I assume 
  53. the following:
  54.  
  55.    Assumption.  
  56.    -----------  
  57.    Updates overwrite our previous knowledge of 
  58.    history and we have no way of remembering 
  59.    the previous version of history.
  60.  
  61.    The resulting database is still 
  62. identical to the one described above in terms 
  63. of a wizzard.  Thus we have a more workable 
  64. definition of a (pure) valid time database.
  65.  
  66. Transaction time database.
  67. --------------------------
  68. Suppse we have a classical snapshot database.  
  69. We are updating this database to keep it 
  70. up to date (as best as we can).  A transaction 
  71. time database is now obtained with the 
  72. capabilities B and C as stated above.  Note that 
  73. such a database is "more than" a rollback 
  74. database.
  75.  
  76. How do the valid time database and 
  77. transaction time database compare now?
  78.  
  79. 1. There is very little difference on 
  80.     how users query them: 
  81.  
  82.    Valid-time query:
  83.    -----------------
  84.    [In reality,] When did John work in Toys?
  85.  
  86.    Transaction-time query:
  87.    -----------------------
  88.    [According to our information in the 
  89.    database,] when did John work in Toys?
  90.  
  91. 2. Both queries are answered by the same 
  92.    algebraic expression:
  93.  
  94.    [[sigma (emp, Name=John, [[Dept=Toys]])]]
  95.  
  96. 3. The update operations are different.  
  97.    In the valid time case, we modify portions 
  98.    of history.  In the transaction time case 
  99.    we modify the current snapshot. 
  100.  
  101. Relaxing the assumptuion.  
  102. -------------------------  
  103. If we assume that not only we can modify 
  104. portions of history, but can remember previous 
  105. versions of history, we have a definition 
  106. of a bitemporal database.  
  107.  
  108. Clearly, in bitemporal database there are two 
  109. time dimensions, the valid time and transaction 
  110. time.  In our bitemporal model, we use finite 
  111. union of rectangles as timestamps.  The above 
  112. query is now asked and formulated as follows:
  113.  
  114.    Bitemporal query.  
  115.    -----------------   
  116.    When did John work in toys. 
  117.    [[sigma (emp, Name=John, [[Dept=Toys]])]]
  118.  
  119.    Again no difference!!!  What does the query 
  120.    retrieve?  In all three cases of valid time, 
  121.    transaction time and bitempopral databases, 
  122.    the query is about the time stamp of the 
  123.    event during which the database John is 
  124.    shown to work in Toys.  
  125.  
  126.  
  127. "As of" queries.  
  128. ----------------  
  129. "As of" are special kinds of queries which were 
  130. introduced by Ben-zwi in his bitemporal model 
  131. during 1979-81.  In data processing applications 
  132. this is a very important class of queries.  
  133.  
  134. Our bitemporal model.  
  135. ---------------------  
  136. In our bitemporal model "as of" are very simple 
  137. queries.  Our model achieves uninhibted navigation 
  138. leading to true orthogonality between valid time, 
  139. transaction time and bitemporal databases. 
  140.  
  141.